CU Amiga Super CD-ROM 27/CU Amiga Magazine's Super CD-ROM 27 (1998)(EMAP Images)(GB)[!][issue 1998-10].iso/GoodBye/JohnKennedy/February96.lha/MASTERCLASS/MASTERAUG.DOC

Text File | 1996-06-02 | 7.8 KB | 268 lines

MasterClass August


If our last scheduled look at ARexx for a while (stop
cheering at the back of the class!) it's probably a good
idea for us to examine the various ways of testing and
debugging programs and scripts.

Even the best programmers in the world write programs with
bugs in them: even me. The knack is to reduce the number and
severity of the bugs to acceptable levels. It's extremely
dangerous to pronouce a program is 100% bug free.

ARexx is a forgiving and flexible language, and will make a
good stab at pointing out any of your most common mistakes.
ARexx also includes some excellent debugging tools for
really getting to grips with your programs and killing the
bugs. (Hey! Did this language really come free with my
Amiga?)


Common Errors

Prevention is always better than cure, and so it's
worthwhile looking at the most common mistakes upfront
rather than trying to debug them after they have been typed
in. Common mistakes are:

* Forgetting to start RexxMast. If RexxMast isn't present,
then ARexx scripts cannot be run. Make sure you have copied
it from your Workbench Extras disk.

* Trying to run a script with the wrong name. You can run an
ARexx script from the Shell with the "RX" command. RX must
be followed by the full name of the program, although if the
program name ends in ".REXX" you can leave this part out.

* If no matter what you type to start the ARexx program, it
keeps returning "Program Not Found" it could be because you
have left out the comment at the start of the program. All
ARexx programs must begin with /* and */ at the very start.

* Sometimes ARexx seems to totally ignore commands in the
script. For example, although Arexx uses the command "SAY"
to display text you might accidentally use "PRINT" instead.
ARexx will simply ignore this. However, if you use "ECHO" it
will work. What's going on? If you use PRINT ARexx thinks
you are using a command from another Host. Unless you happen
to have a program called "print.rexx" present, nothing will
happen. However, when you use Echo text is displayed,
because by default ARexx will let AmigaDOS have a bash and
recognising commands, and of course Echo is a valid AmigaDOS
command.

* All the commands following an IF/THEN clause are not
executed. Let's say you are testing a variable and want
ARexx to perform some actions, like this:

IF score>highscore THEN
    SAY "New high score!"
    highscore=score

Can you spot the bug? After a THEN, only one statement will
be executed which means the statement "highscore=score" will
always be executed. The correct form is:

IF score>highscore THEN
    DO
        SAY "New high score!"
        highscore=score
    END

as this packets up the statements into one DO clause.


* Keep getting "Arithmetic Conversion errors"? This program
may look OK at first glance, but it will crash out with the
arithmetic error. (error.iff)

/* Whoops!*/

x=y+10
say x


The problem is that by default all variables are defined to
containt their own name. This means that the variable Y does
not contain a number (you might expect the value "0") and
instead contains the string "Y". When you try and add a
string to a number you get an error. Do it this way instead:

/* Better! */

y=0
x=y+10
say x


* Other sorts of errors can be harder to detect. For
example, your script may contain a "logic error" in that
your code is perfect, but what your reasoning is flawed. The
program is not bugged as such, you are! ARexx still makes it
easier to find these flaws too, as we'll see.




Stamping on bugs!

A good way to find out what your program is currently up to
is to include "SAY" commands at various points in the
program. For example, if your program is quite large and
uses a lot of functions, it might be a good idea to include
SAY at the begin and end of each function. You can use the
SAY simply to indicate which of the program is actually
executing, or you can use SAY to display the current value
of a variable.

It can also be a good idea to make the SAY conditional, so
that you can switch the message on and off:

if debug=1 then say "Function Zog Started"

You can control the printing of messages by setting "debug"
to 1 or 0 at the start of the script.

However, this is nothing new and in fact ARexx can do it
pretty much automatically, thanks to the TRACE command. At
any point in your program you can include the line TRACE ALL
to switch on special trace output, and then TRACE NORMAL to
switch it back on. Like this:


/* Tracing Example */

say "This is an example.."
do a=1 to 5
    b=a*10
end

trace all
do a=6 to 10
    b=a*10
end
trace normal


This creates output like this:

This is an example..
  9 *-* do a=6 to 10;
   10 *-* b=a*10;
   11 *-* end;
    9 *-* do a=6 to 10;
   10 *-* b=a*10;
   11 *-* end;
    9 *-* do a=6 to 10;
   10 *-* b=a*10;
   11 *-* end;
    9 *-* do a=6 to 10;
   10 *-* b=a*10;
   11 *-* end;
    9 *-* do a=6 to 10;
   10 *-* b=a*10;
   11 *-* end;
    9 *-* do a=6 to 10;
 12 *-* trace normal;


(trace.iff -- Let ARexx show you what's happening with the
Trace command)

Up until the Trace command, nothing happens. However, after
it the display contains the line number of the script,
followed by the statement currently being executed. This
allows you to see which lines in your program are being
processed. Remember, if the text whizzes off your screen too
quickly to see you can redirect it. For example, if the
program is called "plop.rexx", run it like this:

rx plop > ram:debug

This will sent the output of the program to a file called
"debug" in the Ram disk where you can peruse it at your
leisure.

Indidentally, you can use TRACE with several options instead
of FULL such as "RESULTS", which will also display the value
of any expressions calcutated. Use "INTERMEDIATE" if you
want a lot of extra information too.

Sometimes these debugging methods can be confusing,
especially if your program already prints to the screen. For
this reason, ARexx can open a new window especially for
trace output. All you have to do is enter

TCO

at the shell. This stands for "Trace Console Open" and it
will open a new window. This window will display all the
output generate by TRACE. You can close the window by
entering

TCC

which stands for "Trace Console Close".


tco.iff
If asked nicely, ARexx will open up a new window for the
display of all trace output.



If you want to be able to control how the trace operates
whilst the program is running, use another TRACE option such
as this:

trace ?all

which puts the Trace into a special interactive mode. Now
the program will halt after every command with a prompt. You
can either continue to the next instruction by pressing
return, or enter legitimake ARexx commands. For example,
you could end SAY to check on the contents of a variable. Or
switch off the interactive mode by typing:

trace ?

at the prompt again. You can also enter a number which
causes that many commands to be ignored. This is especially
useful when dealing with large loops.


The end

And that's about it! If there are any specific ARexx
questions you which to ask, or if you have any suggestions
for future MasterClass topics, please get in touch either
via the CU address of via email. The email address is
[e-mail], and my Web site is
http://www.webzone1.co.uk/www/johnk






Box out: Good news for ARexx fans!

Last month there was excellent news for graphics users with
a penchant for ARexx, as it was announced that new versions
of both the Photogenics art package and the Imagine
rendering software are to include ARexx support.

For Photogenics this means the ability "batch process" large
numbers of files, as well as define custom built commands.
Imagine users will have the ability to create new object
tools and have an extraordinary degree of control over
animations. With some ARexx scripts it would be possible to
control the position and shape of Imagine objects
mathematically -- let me at it!